reservations-eapi

In order to select the right Retail Service ID (rsid) and service origin date (serviceOriginDate) to submit in Reservation API requests, consumers have to apply some logic for trains which split or join en route (known as associations). Within the RARS platform trains which are impacted by a split or a join are 'expanded' during the import process, to create unique services with the full and correct calling patterns. This requires Reservation API users to be able to uniquely identify these services in order to query availability, retrieve coach information, or to make bookings

The data needed to do this is all available within the existing timetable data feed (RSPS5046). This page provides instructions on how that data can be used to supply the right retail service ID and service origin date in Reservation API requests.

General rules:

The logic for choosing the right retail service ID and service origin date for associated services can be simply expressed as:

• Retail Service ID: The lowest value RSID within a service's published schedule
• Service Origin Date: The origin departure date, after the association has been applied

Notes:

1. Cases of 2 or more services splitting or joining at a calling point are supported by RARS (e.g. Caledonian sleeper at Edinburgh)
2. Associations at multiple calling points are not currently supported in RARS

Join associations:

Using the below as an example of a join association:

Here we have two services, one with a calling pattern A-B-C-D-E-F-G-H and the other with a calling pattern X-Y-Z-D, and a join association record for these two services at D. Upon import into the RARS platform the association will be expanded and these will be stored in RARS as

• A-B-C-D-E-F-G-H and
• X-Y-Z-D-E-F-G-H

The A->H service has two RSIDs recorded in it's schedule. The first, XX123401, is in the BX record and the second, XX123403, is in a CR record at the join location D.

• RARS will assign the lowest RSID, XX123401, to the A->H service.
• The origin after the join association has been applied is A so the serviceOriginDate will be the departure date from A.

The X->H service only has one RSID, XX123402, published in the BX record of its schedule, but inherits XX123403 from the join.

• RARS will assign the lowest RSID, XX123402, to the X->H service.
• As the origin after the join association has been applied is X the serviceOriginDate will be the departure date from X.

Split associations:

Using the below as an example of a split association:

Here we have two services, one with a calling pattern A-B-C-D-E-F-G-H and the other with a calling pattern E-X-Y-Z, and a split association record for these two services at E. Upon import into the RARS platform the association will be expanded and these will be stored in RARS as

• A-B-C-D-E-F-G-H and
• A-B-C-D-E-X-Y-Z

The A->H service has two RSIDs recorded in it's schedule. The first, XX123403, is in the BX record and the second, XX123401, is in a CR record at the split location E.

• RARS will assign the lowest RSID, XX123401, to the A->H service.
• The origin after the join association has been applied is A so the serviceOriginDate will be the departure date from A.

The A->Z service only has one RSID, XX123402, published in the BX record of its schedule, but inherits XX123403 from the split.

• RARS will assign the lowest RSID, XX123402, to the A->Z service.
• As the origin after the split association has been applied is A the serviceOriginDate will be the departure date from A.

Last update: 30-Oct-2024 09.28: ASSIST API Documentation Maintenance: 'reservations-eapi', Version 'v2', Page 'Association logic', Revision 'B'.

To request updates to this text please contact Neil Barkham.